1. Field of the Invention
This invention relates to computer systems, and more particularly to resource pool management in computer systems.
2. Description of the Related Art
A three-tier application is an application that may be organized into three major parts, each of which may be distributed within a networked computer system. The three parts (tiers) may include: one or more clients, one or more servers, and one or more back-end systems (e.g. databases) along with their management functions. In the first tier, a client may be a program running on a user's computer that includes a graphical user interface, application-specific entry forms, and/or interactive windows for interacting with an application. An exemplary client may be a web browser that allows a user to access the Internet. In the second tier, a server may be a program such as an application server that contains the business logic for an application such as banking transactions or purchasing merchandise for the user of a client. The server may be running on one or more computers.
A plurality of client systems may connect to one or more servers as components of a network. An exemplary network of this type is the Internet. Clients may submit requests for data to servers, and if the requested data is available within the server, the server may respond by returning the requested data to the client. When the data requested by a client is not available within a server, a component of the server (requester) may request the data on the behalf of the client from a backend system. This request may require the establishment of a connection between the server and the backend system. A connection is a set of computer system resources and parameters, which allow communications between two or more entities within the system. For example, computers A and B may be components of a computer system, which includes several computers linked together by a communications network. An application running on computer A may reach a point in its execution where it requires data, which is resident on computer B. At this point the application will request that a connection be established between computers A and B whereby, it may obtain the necessary data. In general, some agent within computer A may allocate resources, such as computer memory and buffers, to support the communication and send a message to computer B informing it that a connection is desired. Upon receiving this message, an agent in computer B may allocate resources in computer B to support the communication. At this point a negotiation may take place between the agents in computers A and B, which may include the exchange of several messages. This negotiation may result in a set of parameters, which govern the communication between A and B. These parameters may include: how much data may be sent at one time, what format the data may be in, what to do if an errors during transmission, etc. Depending upon the complexity of the computer system, the negotiations to establish a connection may consume a significant amount of time.
The third tier of a three-tier application may include one or more backend systems. A backend system may include one or more databases and programs that facilitate access to the data they contain. In some implementations of three-tier applications, the number of clients initiating requests for data, and therefore the number of data requests generated may be quite large. Correspondingly, the number of connections between the server and the backend systems needed to fulfill these requests may be quite large. The overhead associated with establishing a connection between the server and backend system may constitute a significant portion of the response time for a request from a client. To reduce the overhead associated with establishing new connections, a server may maintain a pool of pre-established connection, e.g. a connection pool. By the incorporation of a connection pool, the server may be able to significantly reduce response times. When an application component receives a request for data from a client, it may first determine on what backend system and/or in which database the requested information resides. It may then send a request for a connection to the specific backend system to the connection pool. A connection pool manager may then determine if a connection to the specified backend system is available. If such a connection is available, the connection pool manager may supply the connection to the requestor and the requester may then be able to obtain the needed data for the client without incurring the overhead of establishing the connection.
Management of a connection pool may involve an attempt to balance the capacity to fulfill requests for connections with limitations on server resources that may be allocated for the connection pool. It may be desirable to have sufficient connections in the connection pool such that all requests for connections may be fulfilled without the need to establish any new connections. In complex systems where the number of backend entities is great, the number of connections and computer resources needed to support them may exceed the total resources available to the server in which the connection pool is running. Therefore, it may be necessary to limit the number of connections in the connection pool. Given a limitation on resources that may be devoted to the connection pool, it may be desirable to implement a set of connections corresponding to the most frequent connection requests received by the connection pool. It may be that the frequency distribution of requests for connections varies as a function of parameters such as time of day, so that a connection pool containing a set of connections optimized to meet the connection demands of morning clients may be quite different from a set optimized for evening clients.
In order to achieve higher levels of economy of server resources, it may be necessary to be able to change (reconfigure) the connection pool to meet changing demands for connections. Changing the configuration of the connection pool (e.g. to change the pool size or other parameters) may require destroying the pool and reinitializing it with new parameters. This procedure may also entail rebooting the computer on which the connection pool resides. Therefore, reconfiguring a connection pool may require the destruction of all connections within the pool at a minimum. For complex systems with a large number of clients, there may be no time at which one or more connections are not in use. Reconfiguring the connection pool may disrupt service to any clients that are currently using connections. This disruption of client services may be of significant duration, particularly if a reboot of the application server is required.